Injection molding machines of the type covered by this invention have an in-line reciprocating ram or screw which axially moves or translates in a barrel to “inject” plasticized material or melt into a mold having mold halves affixed to platens of a clamp and clamped into a desired position. After injection, the screw maintains pressure on the melt in the mold during a “hold” period while the plastic in the mold solidifies to a desired extent. The screw is then rotated, allowing pelletized plastic from a hopper attached to the barrel to travel within screw flights whereat it is sheared to melt condition and deposited in the barrel in front of the screw. The melt forces the screw rearward until a sufficient quantity of melt is “recovered” at the tip of the screw to form a shot of melt for the next injection cycle. During recover, the mold is opening to allow pins within one of the platens to “eject” the molded part from the mold. After ejection, cores are usually inserted into the open mold and the mold closed and “clamped.” The molding machine operation is thus typically viewed as a cycle or sequence of “clamp,” “inject,” “hold,” “recover” and “eject.”
In reality, the injection molding machine is much more complicated than what the operating sequence may indicate. In fact, the injection molding machine may be thought of as comprising many machines, each of which must perform its own function while interrelating with and, in some instances, comprising a portion of another machine. For example, the translation of the screw within the barrel to achieve injection is performed by hardware separate from hardware that causes the screw to rotate. However, in recover (and in some instances inject) the screw rotates and translates simultaneously. In other instances, the different hardware items operate independently but in staged sequence to related hardware. For example, the hardware controlling the ejector pins fits within the clamp hardware but operates separately therefrom once the clamp starts to open. A similar result applies to the hardware for setting the cores. Still further, there are other hardware items which operate in a manner that can be viewed independently of the molding sequence although affected thereby. For example, heater band hardware maintain a melt barrel temperature and carriage positioning hardware maintains the barrel in contact with the sprue of the mold unless drool requires separation of the barrel tip from the mold. Still further, general purpose injection molding machines, to which this invention is particularly applicable to, must have an ability to interface with and operate in accordance with third party hardware having its own “legacy” controls. For example, gas injection technology may impose a third party mold hardware added to the machine with produces an inert gas backpressure in the mold that has to be accounted for or interrelated with the machine's hardware for injection and hold. Third party robotics are often used to remove parts, change mold halves and place cores and require the machine hardware to account for such equipment. Special hoppers may intermittently dispense different plastics into the screw/barrel during recover. It can thus be readily seen from this general discussion that an injection molding machine is, in fact, a relatively complex system comprising many different hardware items that must operate in a synchronized manner.
Today's typical control system for an injection molding machine includes an operating station which interfaces with the machine operator who specifies general end conditions or set points that the machine must achieve. For example, the operator during set-up will set the speeds at which the mold opens and close, the mold open distance, injection screw velocity or pressure profile, etc. The set point data will be sent to a programmable machine controller, PLC, which has a programmed sequence routine that takes the set point data into the routine and issues control signals to a number of intelligent controller boards that in turn generate command signals to the various hardware items on the machine. For an example, see U.S. Pat. No. 5,062,052. Typically, the operator station is intelligent with its own cpu and memory and the PLC is intelligent with its own cpu and memory as are the controller boards. In fact, the trend is to establish the operator station as a Windows based pc for use with conventional, off-the-shelf software for monitoring, networking, and SPC purposes while using a more robust, fail-safe operating system for the PLC.
Traditionally, the PLC has been programmed through top-down ladder logic diagrams representing the logical operations needed to perform functions as long series of “rungs” or control relays “and'ed” or “or'd” together. This practice continues today, especially for injection molding machine controllers purchased from generic, control system manufacturers who, working with the injection machine builders customize the system to fit the injection molding machine application. Because the complexity of the injection molding machine has increased, the Boolean ladder logic programming requires more complex operations to be performed in the analog boards and in the control loops for the digital boards.
A number of injection molding machine controllers, including those developed by the assignee, have and do use more traditional programming languages such as assembly or higher level languages such as BASIC, C, C++ and the more recent IEC 1131 programming language. In assignee's Pathfinder control system, a number of specific real time tables were developed and the source code was constructed with commands so that any specific command was linked to a real time table and extracted from that table specific instructions or code needed to perform the command. For example, a “move clamp 120 ton” command would extract from a real time table prepared for a 120 ton machine, the code needed to move the clamp the 9″ in travel required by a 120 ton machine clamp. Different tables were then developed for various machines and various options. This approach solved to some extent the problem of avoiding the generation of thousands of new lines of code when changes were made to a base platform injection molding machine. Over time, the real time tables became extensive. However, the tables did not embed or encapsulate the code and did not have a parent/child hierarchal relationship. The controls engineer had to be aware of the communication required between the hardware even though the system was developed to the point where state transitions were placed into real time tables. The system was still highly procedural and “function based.” That is, the method implementing the sequence was not tightly bound to the data related to the hardware. Nevertheless, assignee's prior Pathfinder system was and is well suited for implementing the complex routines that are required to control a general purpose injection molding machine in the context of real time.
The problem confronting today's general purpose, injection molding machine manufacturer is not necessarily the responsiveness or functioning of the machine's controller, but the time and expense required to change the programmed routine when the customer specifies a particular machine from the family of machines offered to the market by the machine builder. Assume that a manufacturer offers a line of hydraulic injection molding machines ranging anywhere from an inject/clamp capacity of 100 tons to 1,000 tons. Obviously, the pump hydraulic circuits change within this range. Because the routines are function based, a family of routines can be developed to address the tonnage changes. Within any given tonnage, however, various components can be spec'd to the customer's requirements. For example, the clamp could be a toggle clamp or alternatively a hydraulic clamp. Within the toggle clamp, the clamp could be a 4 pin linkage or a 5 pin linkage type. Special screws for special plastic molding applications may be supplied and the machine may have to function with several differently designed screws. Because the machines are intensely price sensitive and the component changes materially change the machine price, the components are designed with reliability and price foremost in mind. This means that actuators and controls for any given hardware component in any given class of machine may and do change. In simplest terms, a counter for toggle clamp A may count in millisecond increments. In toggle clamp version B, its counter may count in 10 millisecond increments. While the controls engineer will change the toggle code for that machine if toggle B is supplied, he also has to change a number of other code entries or blocks because of concurrent processing (and state transition). For a simple example, inject start may be enabled based on the clamp close function and the inject start is set at millisecond increments for a “standard” type A clamp. If the counter frequency is changed to 10 millisecond increments because toggle B clamp is used, the inject start procedure has to be changed. Further, while the machine is checked for functionality at the factory prior to shipment, a failure to properly implement all the code changes required by the additional hardware or change hardware may not evidence itself immediately. For example, a problem may not surface until the time the customer attempts to mold a different plastic in a special mold, etc.
Further compounding the problem is the gravitation in the industry from hydraulic powered machines to electric powered machines and to hybrids (see for example U.S. Pat. No. 6,089,849). The machines on a hardware, platform basis are materially different and require different control concepts although the machine sequence remains the same.
In contrast to the structured analysis (SA) methodology achievable by the higher code languages, specifically C++ and IEC 1131 which lend themselves to lifting procedural programming concepts up to the modeling level by functional decomposition and flow of information required in SA approach, there is another modeling approach known as object-oriented (OO), which was developed in the late 1980's and is widely used in business and data domain applications today. Objects, which are instances of a class (alternatively, a class is an abstract of an object), have code indicative of behavioral characteristics and data attributes which have known characteristics of encapsulation, polymorphism, data abstraction, inheritance, etc., and are linked or communicate together to establish a programmed routine. The object characteristics available in object oriented methodology makes the system well suited for modeling the type of control system used in an injection molding machines, particularly the ability to reuse objects when the composition of the machine changes without having to reprogram or debug the entire system. See for example, Real-Time UML: Developing Efficient Objects for Embedded Systems, by Bruce Powel Douglass, Addison Wesley Longman, Inc., 1998. However, the objects required in an injection molding system require considerable programming. Unlike other embedded control systems, injection molding machine controls, at least the injection molding machines which are the subject of this invention, have extensive, sophisticated control laws and considerable hardware that requires a large number of objects and accordingly an extensive amount of OO programming has to be written.
As of the date of this invention, OO methodology has not been believed used heretofore to control the entire machine or to model the routine used to control the machine. It is not known, but it is believed possible, that certain components of an injection molding machine, which could include third party auxiliaries, may have used OO techniques to develop a block of code used for that component which may be interfaced with or incorporated into the overall control scheme. In this regard, it should be noted that certain programming languages, specifically C++ as it has evolved from C, does have certain blocks of code or subroutines that build objects in an OO sense, and a programmed system with C++ will have objects formed by the code. The system, however, simply because it is programmed with C++ language is not an object oriented programming system. In contrast, the development system, Smalltalk, is developed for use in an object oriented control system. The programming language requires all code to be written about classes and data in object form. However, neither Smalltalk (nor Java) have been believed used to control an injection molding machine in hard real time because considerations related to speed and performance indicate that such programming languages are not preferred for injection molding machines.